\documentstyle[insertplot]{article}
\input prepictex
\input pictex
\input postpictex
\begin{document}
\title{First report of the Algrebra Assistant}
\author{Michael Richardson\\
mcr@physics.carleton.ca}
\date{\today}
\maketitle
\pagebreak
\section{Overview}

The Algebra Assistant is a project to build an interactive equation
editor that promotes exploration of mathematics by removing some of
the tedium associated with doing algebra. With less tedium, less
errors due to inattention occur, and more possible routes of attack
can be considered before frustration sets in.

The Algebra Assistant is concurently conceived to have three major
components:
\begin{enumerate}
\item[graphics interface]
An X window interface provides the maximum portability for the
application. Providing graphics not only makes the equations look
nice, but allows the user to retain all the prior knowledge they
might have with at the chalkboard. An ascii interface would at best be
a kludge, and would require the user to learn a new set of symbols.

\item[editor]
The system must provide a mechanism to take an equation and edit it in
the normal ways that one typically does on a chalkboard: this usually
involves writing down an equation (possibly giving it a name), and
then transforming it by doing substitutions, multiplying by unity
(that is, cancelling terms top and bottom, or rationalizing a
denominator), and adding and subtracting unity (either to move a term
from one side of an equation to the other, or to do things like
completing a square). 

\item[grinder]
As a support tool for the above, the system needs to be able to
provide a simple level of assistance. All of the operators and symbols
being manipulated having some meaning, and the user should be able to
request that a particular operation be interpreted. This can be
particularly usefull when it comes to doing things like taking
derivatives of complicated equations, or doing integrals. It is not
suggested that this grinder be all encompasing, but rather that it
provide simplications that are easy to do, and provide interface(s) to
larger, more complete programs such as Maple,
%{\footnote product of University of Waterloo}
Macsyma, etc.
%{\}
\end{enumerate}

These portions of the system will be developed in a language called
Self. Please see the Self documentation for a proper overview of the language.

\section{Work done}

At the date of this writing, the first part, the graphics interface
has been mostly completed. Windows open, equations are rendered in the
windows, and refreshed when required, and some support for fonts
exist. 

A somewhat primitive interaction model based mostly on X events has
been written by James Noble of Victoria University, Wellington
<kjx@comp.vuw.ac.nz>, and this was heavily modified and subclassed to
provided the required flexibility. The {\em Navel}\footnote{To look at
one's Self, use your {\em Navel}} view manager is far from complete,
and is rather experimental at this time.

In support of the above, several pieces were constructed: 
\begin{itemize}
\item[poly] a set of objects to describe scalars, vectors, and various
kinds of operators. This has mostly just been sketched out, and many
of the finer details and embellishments need to be added.

\item[boites\footnote{This is french for box. The Scheme code that
this was ported from used the symbol {\em box} for such things as lazy
evaluation}] a set of objects that provides formatting control for
equations. Inspiration for these objects, and the algorithms were
taken from Donald Knuth's TeXbook description of the \TeX formatter.
The chapters on Glue and Building boxes were particularly important.

\item[window] These objects inherit from the {\em Navel} system and
provide specialization of the response to various events such as {\em
redraw} and {\em configureNotify}\footnote{indicates the window has
changed shape}. The {\em equationView} object knows how to convert a
{\em poly} object into its {\em boites} representation, and then ask
the {\em boites} to draw themselves. The {\em boites} are 
independant of what they are drawing on so long as they have accurate
ideas of how big the primitive objects are. (That is, how big the
fonts are). This is currently specific to X windows, both in the way
the size of a string of characters is discovered, and the naming
of the fonts. (Naming of fonts should properly be done via X
resources in order to be X server imdependant. However, most servers
do provide something usefull named {\tt fixed} and have a font named
{\tt Symbol}
\end{itemize}

\section{Things to do}

The next stage of work needs to be in the area of the editing
facilities. Further structure needs to be added to establish the
connection between a mouse click in the window, the {\em boite}
structure that represents the displayed version of the equation, and
the equation itself. 

One suggestion is to make the current view system somewhat lighter
weight. The boite structures would become specializations of some kind
of view object structure. Currently views are associated only with
actual X drawable structures. 

\pagebreak
\section{Structure of the system}

\input poly-struct.pictex

\end{document}

